home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄19⁄90 / 0462-Persistent Objects-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.8 KB  |  78 lines  |  [TEXT/GEOL]
  1. Item    4273821                         18-Jan-90        21:46
  2.  
  3. From:   D4384                           US Voting Mach, Sarner, Calvin,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Persistent Objects
  8.  
  9. TO: Compatriots MACAPP.TECH$
  10. FROM: Greg Colvin (link D4384)
  11.  
  12. I think I have a solution (or at least a hack) to the persistent object
  13. problem. I coded it months ago as insurance against 7.0 not being available in
  14. time, but have not yet exercised the code, as everything fits in memory so far
  15. (and my client doesn't trust the whole idea anyway!). The recent discussion in
  16. the archives makes me worry that perhaps it isn't that simple.
  17.  
  18. My idea is to keep a copy of the object on a file, and keep in memory only
  19. enough information to read in the object when necessary. To this end I have
  20. created two new classes. In simplified form they are:
  21.  
  22. TFileObject= OBJECT(TObject)
  23.        itsLock:  TFileLock;                { info for maintaining locks }
  24.        PROCEDURE TFileObject.Delete;          { Say goodnight, Dick. }
  25.        FUNCTION  TFileObject.GetBuff(VAR buff: Ptr): INTEGER;  { get record dat
  26.        FUNCTION  TFileObject.PutBuff(VAR buff: Ptr): INTEGER;  { put record dat
  27.        PROCEDURE TFileObject.LockForRead;    { ALWAYS CALL BEFORE READ !!! }
  28.        PROCEDURE TFileObject.LockForWrite;  { ALWAYS CALL BEFORE WRITE !!! }
  29.        PROCEDURE TFileObject.Unlock;          { ALWAYS CALL AFTER LOCK !!! }
  30.        FUNCTION  TFileObject.Clone: TObject; OVERRIDE;
  31.        PROCEDURE TFileObject.Copy(source: TFileObject);
  32.        PROCEDURE TFileObject.Init;
  33.    END;
  34.  
  35. TFileLock= OBJECT(TObject)
  36.        itsObject:  TFileObject;    { locked object }
  37.        fileOffset: LONGINT;        { offset of object data in document file }
  38.     dataSize,                   { size of object data in document file }
  39.     readLock,
  40.     writeLock:  INTEGER;
  41.     {... other fields and methods for counting locks, maintaining cache, etc. }
  42.        PROCEDURE TFileLock.SwapIn;  { get data from file into object}
  43.        PROCEDURE TFileLock.SwapOut;{ put object data into file }
  44.        PROCEDURE TFileLock.Delete;  { delete this object from file }
  45.    END;
  46.  
  47. Since the ClassID for an object is stored as an integer at the head of the
  48. object (or at least it must be for the UMacApp source to work), and the ClassID
  49. should suffice to invoke class methods, I figure that all that needs to stay in
  50. memory is the ClassId and itsFileLock.  When I need to use an object I call
  51. LockForRead or LockForWrite, which calls itsLock.SwapIn to increment a lock
  52. counter and get the object data into memory. When I not using the object I call
  53. Unlock, which decrements the lock counter. When the write lock counter
  54. decrements to 0 the object fields are written to memory, using the appropriate
  55. PutBuff method. When memory in the Zone for object caching is low, the Memory
  56. Manager invokes a growZone function that invokes SwapOut on the least recently
  57. used objects that have no locks on them. SwapOut copies the object fields to
  58. disk, using the appropriate PutBuff method, and uses ReAllocHandle to keep only
  59. the INHERITED TFileObject in memory (that is, a valid ClassId and a handle to
  60. itsFileLock). SwapIn can then use ReAllocHandle and the appropriate GetBuff
  61. method to read the object fields back into memory.
  62.  
  63. I have noticed that the MacApp debugger dislikes this trick, as the dehydrated
  64. form of the object fails the IsObject test! Things seem OK as long as the
  65. debugger is turned off. All the above REQUIRES that the portion of the object
  66. that remains in memory is adequate to invoke its LockForRead and LockForWrite
  67. methods, and that the reconstituted object is in fact still a valid object. Is
  68. this true? Or is it not nice to fool Mother MacApp?
  69.  
  70. Could someone tell me if I am badly off the track? I am not yet on the group
  71. address (any day now), so a direct link would be appreciated.
  72.  
  73. Thanks,
  74.  
  75. Greg Colvin
  76. D4384
  77.  
  78.